Method and System for Controlling Risk in a Payment Transaction

ABSTRACT

Example embodiments of the presently described subject matter are described that require a customer to use a secure payment token if, during a payment transaction, it is determined that the payment transaction poses a risk. A risk analysis may be performed based at least in part on data related to the payment transaction, such as data related to the customer, the transaction itself, the merchant, etc. If the results of the risk analysis indicate that an unacceptable amount of risk exists, the merchant or any interested party may require the customer to use a secure payment token, for example, a smart card, to conduct the transaction. Otherwise, the customer may proceed by using a static payment token, for example a credit card or PIN/password-based payment token.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.11/767,461 filed Jun. 22, 2007, which is a National Phase ofInternational Application PCT/US08/062208, entitled Method And SystemFor Controlling Risk In A Payment Transaction, filed May 1, 2008, whichclaims priority to U.S. provisional patent application 60/915,861,entitled Method and System for Controlling Risk in an E-CommerceTransaction, filed May 3, 2007, which are hereby incorporated byreference in their entirety herein.

BACKGROUND

Performing transactions remotely, such as over the Internet or othercomputer networks, using a payment token (e.g., a payment card) hastraditionally presented a higher risk of fraud because the merchant isnot able to verify the identity of the person presenting the paymenttoken data, and no physical signature may be received from the tokenholder at the time of the transaction.

Various techniques have been developed to minimize the possibility offraudsters submitting stolen payment token information when conductingtransactions remotely. One such technique offered by MasterCardWorldwide is known as SECURECODE™, which penults cardholder verificationand/or authentication at the time of an online transaction. In oneimplementation of the technique, before attempting a transaction, thecardholder is requested to enroll in the program by visiting aregistration website where, after confirming that the account iseligible for enrollment in the program, the identity of the cardholderis verified by prompting the cardholder to answer one or more securityquestions, or other techniques. Once the identity of the cardholder isverified, the cardholder is prompted to set up and define his or herSECURECODE, which is a PIN or password known only to the cardholder.This SECURECODE is then stored in a secure database available to thefinancial institution that issued the payment card, and used forsubsequent cardholder verification.

When the cardholder subsequently attempts to use the payment card at anonline merchant, the cardholder's card number is entered into a webform, or otherwise made available to the merchant, and the merchant'scomputer queries a directory to verify if the card is within a range ofcard numbers that participate in the SECURECODE program. Rather thanconsulting a directory server, the merchant may instead query a localcache of participating card number ranges. If the card number used iswithin a participating range, the merchant then sends a message to acomputer maintained by the issuer or its representative, to determine ifthe account being used is enrolled in the SECURECODE program. If thecard account being used is enrolled, the merchant sends an instructionto the cardholder's computer, which then initiates communication withthe issuer's computer. The cardholder is prompted to enter his or herPEN or password in a box on the cardholder's computer screen. The PIN orpassword is then verified by the issuer. If the issuer determines thatthe correct PIN or password has been entered, the issuer generates anAccountholder Authentication Value (AAV), which is returned to themerchant's web server application. Thereafter, the traditional paymentprocessing occurs, except that the AAV is inserted in the authorizationrequest message generated by the financial institution with whom themerchant maintains a relationship. The AAV is then used by the issuer toverify that the identify of the cardholder performing the onlinetransaction has been verified using the SECURECODE process beforereturning an authorization response message to the merchant, or themerchant's acquirer.

In another embodiment of the SECURECODE process, rather than using astatic PIN or password, the cardholder is provided with an intelligenttoken, such as an IC card or a contactless device, as well as anintelligent card reader, to interact with the intelligent token. In thisapproach, the cardholder is prompted to use the token to generate adynamic security code, which is entered into a web form by thecardholder, or the intelligent token reader, and the dynamic securitycode is submitted to the issuer transaction to authenticate thecardholder. Such a system is described in more detail in U.S. patentapplication Ser. No. 10/506,016, entitled “Authentication ArrangementAnd Method For Use With Financial Transactions,” filed on Feb. 28, 2003,which is incorporated by reference herein in its entirety.

While the use of a static PIN and/or password can be effective atdeterring or preventing fraudulent online transactions using stolenpayment token information, this approach is not effective unless thetoken holder registers the payment token with the issuer in the program,and associates a PIN or password with the account. In somecircumstances, it may be possible to force the token holder to registerthe token in the program the first time the token holder attempts anonline purchase using a payment token that is eligible for use with thesecure transaction program. Alternatively, the cardholder may be allowedto decline to register a predetermined number of times, before beingforced to register in the program before further E-commerce or onlinetransactions are permitted.

In some online or E-commerce transactions, however, the risk of fraud isnot great enough to justify requiring a token holder to register his orher account and create a SECURECODE PIN or password. Additionally, evenwhen a token holder is registered with a secure transaction program, thenature of the transaction may not justify the additional time and burdenof requiring the PIN or password be verified before permitting thetransaction.

SUMMARY

Methods and systems for controlling risk in a payment transaction aredescribed herein.

One example embodiment may include a procedure for controlling risk in apayment transaction between a customer and a merchant using a securepayment token comprising receiving transaction data related to saidpayment transaction; performing a risk analysis, said risk analysisbased at least in part on said transaction data; and requiring saidpayment transaction to be conducted using said secure payment tokenbased at least in part on the result of said risk analysis.

One example embodiment may include the procedure wherein said paymenttransaction is an E-commerce transaction. One example embodiment mayinclude the procedure wherein said requiring said payment transaction tobe conducted using said secure payment token includes requiring saidmerchant to conduct said payment transaction using said secure paymenttoken. One example embodiment may include the procedure wherein saidrequiring said payment transaction to be conducted using said securepayment token includes requiring said customer to conduct said paymenttransaction using said secure payment token. One example embodiment mayinclude the procedure wherein said risk analysis is based at least inpart on data related to said customer. One example embodiment mayinclude the procedure wherein said risk analysis is based at least inpart on data related to said merchant. One example embodiment mayinclude the procedure wherein said risk analysis is based at least inpart on data related to said payment transaction. One example embodimentmay include the procedure further comprising receiving attempttransaction data, said attempt transaction data generated from a priorattempt to conduct said payment transaction with a static data paymenttoken, wherein said risk analysis is based at least in part on saidattempt transaction data.

One example embodiment may include a procedure for controlling risk in apayment transaction between a customer and a merchant using a securepayment token comprising receiving the results of performing a riskanalysis, said risk analysis based at least in part on said transactiondata, said transaction data related to said payment transaction; andrequiring said payment transaction to be conducted using said securepayment token based at least in part on the result of said riskanalysis.

One example embodiment may include a computer readable medium includingexecutable instructions thereon for controlling risk in a paymenttransaction between a customer and a merchant using a secure paymenttoken, the instructions comprising the steps of receiving transactiondata related to said payment transaction; performing a risk analysisbased at least in part on said transaction data; and requiring saidpayment transaction to be conducted using said secure payment tokenbased at least in part on the result of said risk analysis.

One example embodiment may include the computer readable medium whereinsaid payment transaction is an E-commerce transaction. One exampleembodiment may include the computer readable medium wherein saidrequiring said payment transaction to be conducted using said securepayment token includes requiring said merchant to conduct said paymenttransaction using said secure payment token. One example embodiment mayinclude the computer readable medium wherein said requiring said paymenttransaction to be conducted using said secure payment token includesrequiring said customer to conduct said payment transaction using saidsecure payment token. One example embodiment may include the computerreadable medium wherein said risk analysis is based at least in part ondata related to said customer. One example embodiment may include thecomputer readable medium wherein said risk analysis is based at least inpart on data related to said merchant. One example embodiment mayinclude the computer readable medium wherein the risk analysis is basedat least in part on data related to said payment transaction. Oneexample embodiment may include the computer readable medium wherein saidcontrolling risk further comprises the steps of receiving attempttransaction data, said attempt transaction data generated from a priorattempt to conduct said payment transaction with a static data paymenttoken, wherein said risk analysis is based at least in part on saidattempt transaction data.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of example embodiments of thepresently described subject matter and its advantages, reference is nowmade to the following description, taken in conjunction with theaccompanying drawings, in which:

FIG. 1 is a flowchart of a procedure according to one example embodimentof the presently described subject matter.

FIG. 2 is a block diagram of components according to one example of thepresently described subject matter.

DETAILED DESCRIPTION

Generally, example embodiments of the presently described subject matterare described that require a customer to use a secure payment token if,during a payment transaction, it is determined that the paymenttransaction poses a risk. A risk analysis may be performed based atleast in part on data related to the payment transaction, such as datarelated to the customer, the transaction itself, the merchant, etc. Ifthe results of the risk analysis indicate that an unacceptable amount ofrisk exists, the merchant or any interested party may require thecustomer to use a secure payment token, for example, a smart card, toconduct the transaction. Otherwise, the customer may proceed by using astatic payment token, for example a credit card or PIN/password-basedpayment token.

In this way, a customer, merchant, customer account provider, paymenttoken issuer, or any interested third party may minimize risk inelectronic payment transactions by requiring transactions that pose arisk to be performed in a more secure manner.

FIG. 1 depicts an example procedure according to an example embodimentof the presently described subject matter. A customer may initiate apayment transaction (block 100). It is contemplated that the customermay be present at a merchant site, for example, a customer presentinggoods for purchase at a traditional merchant store. It is alsocontemplated that the customer may be at a location remote from themerchant, for example, conducting a transaction over a datacommunications network such as the internet or the telephone. Once thecustomer initiates the payment transaction (e.g., a request to purchasegoods or services from the merchant), the merchant may form a paymenttransaction message. The payment transaction message may include anydata necessary to complete the transaction, for example, any of,combinations of, or all of, the customer's name, address, billinginformation, the merchant's name, identifying information for themerchant, customer account, merchant account, payment token issuerinformation, etc. For example, a customer wishing to purchase goods froma merchant's website may fill out a web form with data related to thetransaction. A purchase request, in the form of an HTTP message may besent over a data communications infrastructure to the merchant's site.

Once the merchant has received the payment transaction message, themerchant may send transaction data (e.g., the request itself, dataderived therefrom, or any appropriate data related to the purchaserequest) to a risk analyzer (block 102). The transaction data mayinclude any data required to perform a risk analysis of the paymenttransaction. In one example embodiment, the transaction data may berelated to the customer, merchant, payment token, or any appropriateaspect of the purchase request. For example, data related to thecustomer may include the customer's name, history of past transactions,history of fraud, length of time that the customer has been affiliatedwith a traditional payment token issuer, or the like. In another exampleembodiment, data related to the merchant may include the merchant'sname, geographic location of the merchant, history of the merchant'sdeclined transactions, the length of time that the merchant has been inbusiness, the merchant's credit rating, etc. In another example, datarelated to the transaction itself may include the time, date, amount ofthe transaction, type of goods or services to be purchased, originatingcountry, etc. In another example, data may be tangentially related tothe payment transaction, such as the level of security in the datatransfer protocols used between the customer and the merchant or betweenthe merchant and a payment account provider, whether the paymenttransaction is subject to an intermittent spot check, etc.

A risk analysis may be performed based at least in part on thetransaction data or other relevant data (block 104). The risk analysismay include making an observation and determining whether theobservation satisfies a particular condition. For example, a conditionmay include whether the customer account appears on a list of accountsto which fraudulent activity has been linked. In another example, acondition may include whether the amount of the transaction is above athreshold amount. In another example, a condition may include whetherthe type of goods or services is a type for which a high number offraudulent transactions has previously been reported. In practice, therisk analysis may be performed based on any data relevant to theparticular requirements of the system.

If a risk level, as determined by the results of the risk analysis, isunacceptable (block 106) (e.g., above a particular risk threshold), thenthe merchant or customer may be required to conduct the paymenttransaction using a secure payment token rather than a static paymenttoken (block 110). Otherwise, the merchant or customer may complete thetransaction using a static payment token (block 108). For example, therisk analyzer may receive the merchant's name and search a list ofmerchants through which known fraudsters have conducted transactions inthe past. If the merchant's name appears on the list, the risk level forthe transaction may dictate that the merchant must conduct thetransaction using a secure payment token.

FIG. 2 depicts example components according to an example embodiment ofthe presently described subject matter. A customer terminal 200 may bein communication with a merchant 212 over a data communicationsinfrastructure 210. The merchant 212 may be in communication with apayment token issuer 214 over the data communications infrastructure210. A customer wishing to purchase a product or service from themerchant 212 may select a product or service from the merchant 212. Forexample, the merchant 212 may maintain an internet site. The customermay use customer terminal 200 to access the merchant's internet siteover data communications infrastructure 210. The customer terminal 200may include facilities for the customer to browse the merchant'sinternet site, such as display device 202 to view the products and fornavigation on the site. The customer terminal 200 may also include inputdevice 204 to make selections of products and services to be purchasedas well as to navigate the merchant's site. It is contemplated that thedisplay device may communicate with the customer in any appropriatemedium, including visual, aural, tactile, combinations of the foregoing,etc. It is contemplated that the input device may also accept input invarious media, including physical input (e.g., a keyboard, mouse, peninput, etc.), aural input, combinations of the foregoing, etc. Thedisplay device 202 and input device 204 may include one or more devicesfor performing the operations required.

The customer terminal 200 may also include payment facilities forconducting payment transactions with the merchant 212. Paymentfacilities may include a static payment device 208 and/or a securepayment device 206. If the customer is required to conduct the paymenttransaction using the secure payment device 206, then the secure paymentdevice 206 may be used. Otherwise, the customer may conduct thetransaction using the static payment device 208.

The static payment device 208 may be capable of interacting with staticpayment tokens. Static payment tokens may include payment tokens whichinclude static data, for example, data encoded on a magnetic stripe of acredit card, a static PIN/password entered with a transaction, etc. Inone example, a static payment token such as a credit card may be read bya static payment device such as a card reader. A static payment devicemay also include a keypad by which a customer may enter a PIN. The PINmay be static owing to the fact that it remains the same unless changedby the customer. For example, a payment token which requires thecustomer to enter a PIN/password to authenticate the transaction may beconsidered static. This payment token may be relatively easy to copy byfraudsters because the latter need only obtain the payment token and thestatic PIN/password to pose as the customer.

The secure payment device 206 may be capable of interacting with securepayment tokens. Secure payment tokens may include, for example, paymenttokens capable of generating dynamic data to be used during a paymenttransaction. For example, payment tokens that generate dynamic data mayinclude smart cards with embedded processors, a secure key fob withchanging data from which the user reads and enters the data for thepayment transaction, etc. Generating dynamic data to be used in apayment transaction may improve the security of the transaction bymaking it more difficult for a fraudster to copy and use payment tokens.For example, a secure payment token may include a payment token capableof performing operations to encrypt transaction messages. The encryptionmay be based on information known to the account provider and the securepayment token/customer, for example, a shared secret key orpublic/private key information. Unless the fraudster is able to obtainthe secret information, obtain the payment token, and perform thenecessary operations to encrypt the data, the fraudster will be unableto generate the dynamic data necessary to conduct the transaction. Otherforms of securing transactions using dynamic data are well known tothose ordinarily skilled in the art.

Once the selection of a product or service has been accomplished, thecustomer terminal 200 may send a payment transaction message to themerchant site over the data communications infrastructure 210. It iscontemplated that the data communications infrastructure may includedata networks and processor busses and may include local or wide areacommunications. The specific implementation of the data communicationsinfrastructure, unless specified, is immaterial to the principles of thepresently described subject matter.

A risk analysis may be performed, and the merchant 212 may receive theresults of the risk analysis. The risk analysis may be based at least inpart on data related to the payment transaction. For example, themerchant 212 may generate transaction data from the payment transactionand send the transaction data to the payment token issuer 214 over thedata communications infrastructure 210.

A risk analysis component or risk analyzer 216 may perform the riskanalysis and send the results of the risk analysis back to the merchant212. The merchant 212 may determine based at least in part on theresults of the risk analysis that the payment transaction poses a risk.In one example embodiment, the risk analysis component itself maydetermine that a risk exists.

The risk analyzer may be operated by any entity, for example, themerchant, the payment token issuer, an organization specialized inperforming risk analyses, etc.

In one example embodiment, the merchant or customer may be required toconduct the payment transaction using the secure payment token owing tothe fact that a risk has been identified. Requiring the merchant orcustomer to conduct a payment transaction using the secure payment tokenmay include any operations which prevent the merchant or customer fromproceeding forward with the transaction without the secure paymenttoken. For example, the payment token issuer may receive the results ofa risk analysis and where the risk level is higher than a certainthreshold, the payment token issuer may refuse to proceed with thepayment transaction if the secure payment token is not used. In anotherexample embodiment, the merchant may receive a message from the paymenttoken issuer, or any other entity, that indicates the type of paymenttoken to use. For example, the message may include a flag set toindicate that the transaction requires the merchant to process thetransaction using the secure payment token.

In one example embodiment, the secure payment token may include theintegrated circuit card described in U.S. patent application Ser. No.10/506,016, which is incorporated by reference herein.

A requirement for the merchant or customer to conduct the paymenttransaction using the secure payment token may be imposed by anyappropriate entity. For example, a third party risk analyzer, distinctfrom the payment token issuer or merchant, may analyze the risk andprovide the merchant or the payment token issuer with a messagereflecting its decision of whether a secure payment token should beused. The merchant may itself impose this requirement by refusing toproceed with completing the transaction with the customer. The paymenttoken issuer may itself impose this requirement by refusing to remitfunds to the merchant's account if the secure payment token is not used.

If no risk is identified, the customer may be permitted to complete thetransaction using the static payment device.

In one example embodiment, the results received which are related to aperformed risk analysis may include the evaluation of the risk analysisitself or data derived therefrom. For example, the results may include acode indicating which payment token to use in the transaction. This codemay depend, at least in part, on the evaluation of the risk analysis. Inanother example, the results may include a score of risk. In yet anotherexample, the results may include a value indicating whether the risk isor is not acceptable.

The foregoing merely illustrates the principles of the presentlydescribed subject matter. Various modifications and alterations to thedescribed embodiments will be apparent to those skilled in the art inview of the teachings herein. It will thus be appreciated that thoseskilled in the art will be able to devise numerous techniques which,although not explicitly described herein, embody the principles of thedescribed subject matter and are thus within the spirit and scope of thedescribed subject matter.

1. A method for controlling risk in a payment transaction between acustomer and a merchant using a secure payment token comprising:receiving transaction data related to said payment transaction;performing, by a risk analyzer comprising a non-transitory computerreadable medium including executable instructions thereon, a riskanalysis, said risk analysis based at least in part on said transactiondata; and requiring said payment transaction to be conducted using saidsecure payment token based at least in part on the result of said riskanalysis.
 2. The method of claim 1, wherein said payment transaction isan E-commerce transaction.
 3. The method of claim 1, wherein saidrequiring said payment transaction to be conducted using said securepayment token includes requiring said merchant to conduct said paymenttransaction using said secure payment token.
 4. The method of claim 1,wherein said requiring said payment transaction to be conducted usingsaid secure payment token includes requiring said customer to conductsaid payment transaction using said secure payment token.
 5. The methodof claim 1, wherein said risk analysis is based at least in part on datarelated to said customer.
 6. The method of claim 1, wherein said riskanalysis is based at least in part on data related to said merchant. 7.The method of claim 1, wherein said risk analysis is based at least inpart on data related to said payment transaction.
 8. The method of claim1, further comprising: receiving attempt transaction data, said attempttransaction data generated from a prior attempt to conduct said paymenttransaction with a static data payment token, wherein said risk analysisis based at least in part on said attempt transaction data.
 9. A methodfor controlling risk in a payment transaction between a customer and amerchant using a secure payment token comprising: receiving the resultsof performing a risk analysis, said risk analysis based at least in parton said transaction data, said transaction data related to said paymenttransaction; and requiring said payment transaction to be conductedusing said secure payment token based at least in part on the result ofsaid risk analysis.
 10. A non-transitory computer readable mediumincluding executable instructions thereon for controlling risk in apayment transaction between a customer and a merchant using a securepayment token, the instructions comprising the steps of: receivingtransaction data related to said payment transaction; performing a riskanalysis based at least in part on said transaction data; and requiringsaid payment transaction to be conducted using said secure payment tokenbased at least in part on the result of said risk analysis.
 11. Thecomputer readable medium of claim 10, wherein said payment transactionis an E-commerce transaction.
 12. The computer readable medium of claim10, wherein said requiring said payment transaction to be conductedusing said secure payment token includes requiring said merchant toconduct said payment transaction using said secure payment token. 13.The computer readable medium of claim 10, wherein said requiring saidpayment transaction to be conducted using said secure payment tokenincludes requiring said customer to conduct said payment transactionusing said secure payment token.
 14. The computer readable medium ofclaim 10, wherein said risk analysis is based at least in part on datarelated to said customer.
 15. The computer readable medium of claim 10,wherein said risk analysis is based at least in part on data related tosaid merchant.
 16. The computer readable medium of claim 10, wherein therisk analysis is based at least in part on data related to said paymenttransaction.
 17. The computer readable medium of claim 10, saidcontrolling risk further comprising the steps of: receiving attempttransaction data, said attempt transaction data generated from a priorattempt to conduct said payment transaction with a static data paymenttoken, wherein said risk analysis is based at least in part on saidattempt transaction data.